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ABSTRACT 


Type  inference  in  interactive  programming  environments  falls  short  in  two  re¬ 
spects.  The  ability  to  type  check  definitions  one  at  a  time,  and  to  type  check  some 
definitions  but  not  all  after  one  definition  is  modified  is  called  incremental  on-line 
type  inference.  Current  interactive  programming  environments  perform  batch  type 
inference  and  require  extensive  type  recomputation  for  small  changes. 

We  give  an  algorithm  for  on-line  type  inference  that  is  implemented  as  an  at¬ 
tribute  grammar.  From  this  grammar  an  editor  was  automatically  generated  that 
performs  on-line  type  inference. 

The  editor  infers  types  incrementally  due  to  a  well-known  reduction  we  used 
from  Hindley- Milner  type  inference  to  first-order  unification.  Unlike  other  efforts, 
our  algorithm  for  on-line  type  inference  is  truly  incremental. 
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I.  INTRODUCTION 


Interactive  programming  environments  can  significantly  improve  resource  uti¬ 
lization  and  programmer  productivity.  Current  interactive  programming  environ¬ 
ments,  however,  have  not  completely  resolved  some  critical  issues  and  consequently 
typically  offer  limited  support  for  the  programmer.  Programming  environments  of 
the  future  will  need  to  offer  much  more  in  the  way  of  language-based  support,  such 
as  type  checking.  A  language- based  editor  ought  to  detect  and  report  type  errors  as 
they  occur.  The  traditional  edit-compile-debug-run  environment  can  require  hun¬ 
dreds  or  even  thousands  of  lines  of  code  to  be  recompiled  for  something  as  trivial  as 
a  missing  semicolon.  The  problem  is  that  the  environment  in  which  the  program  is 
created  typically  knows  very  little  about  the  language  being  used.  It  is  only  when 
the  program  is  passed  to  the  compiler  that  the  programmer  receives  any  feedback. 

An  interactive  programming  environment  integrates  many  of  the  separate  «is- 
pects  of  current  programming  environments.  Type  checking  in  an  interactive  pro¬ 
gramming  environment  is  on-line  in  the  sense  that  definitions  may  be  type  checked 
one  at  a  time  as  they  are  entered  into  the  system.  On-line  type  checking  will  pro¬ 
vide  the  programmer  immediate  feedback.  This  means  that  at  any  stage  of  program 
development  the  interactive  environment  will  provide  feedback  about  the  type  cor¬ 
rectness  of  the  program  even  if  the  program  is  only  partially  complete.  Consider  the 
following  partial  definition  for  a  function  that  computes  the  length  of  a  list  given  in 
Standard  ML  [Ref.  11]  notation: 

fun  length  1  » 
case  1  of 
[]  ®>  <exp> 

I  <pat>  »>  <ezp> 
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In  the  notation  for  Standard  ML  "[]”  is  the  empty  list.  The  definition  for  length  is 
not  complete  (the  incomplete  term  for  a  pattern  is  denoted  by  <pat>  and  the  un¬ 
specified  expressions  are  denoted  by  <exp>),  yet  we  may  still  derive  a  type  according 
to  the  rules  discussed  in  Chapter  II  and  given  in  [Ref.  8].  The  type  we  can  derive 
is  Va.VJ.hs^a  — ►  J.  This  notation  is  the  standard  notation  found  in  [Ref.  8]  and  is 
discussed  in  more  detail  in  Chapter  II. 

Interactive  programming  environments  exist  that  perform  limited  type  checking 
but  they  are  not  on-line.  For  a  pair  or  set  of  mutually  recursive  definitions,  the 
programmer  must  explicitly  provide  all  the  definitions  of  the  mutually  recursive  set, 
otherwise  an  error  results.  This  is  because  environments  such  as  Standard  ML  use 
an  extension  of  Damas  and  Milner’s  algorithm  W  [Ref.  8],  that  is  an  algorithm 
for  the  batch  type  checking  problem.  A  batch  type  checker  reports  an  error  upon 
detecting  an  unbound  identifier.  A  unbound  identifier  is  one  for  which  no  definition 
is  provided.  The  problem  is  that  all  the  definitions  in  the  sequence  must  be  supplied 
otherwise  the  batch  type  checker  complains  about  the  unbound  identifiers. 

Type  checking  in  an  interactive  programming  environment  is  an  on-line  problem 
vice  a  batch  problem.  Definitions  are  type  checked  one  at  a  time  and  the  type  checker 
must  not  object  to  undefined  free  identifiers.  Rather,  when  a  definition  is  provided 
the  type  checker  must  ensure  that  the  definition  is  used  correctly.  Consider  again 
the  definition  for  length  given  above.  We  can  fill  in  some  of  the  missing  information. 

fun  length  1  * 
case  1  of 

□  »>  0 

I  <pat>  «>  <exp> 

t 

Now  we  can  type  the  definition  of  length  Va.lista  —*  int.  As  we  shall  see  later,  this 
type  implies  length  will  accept  a  list  of  elements  of  any  type  as  input  and  return  the 
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length  of  the  list.  This  type  can  be  determined  even  though  the  definition  is  not 
complete. 

We  complete  the  definition  for  length  so  that  we  have: 

fun  length  1  = 
case  1  of 
[]  =>  0 

1  (h;:t)  =>  1  +  (length  t) 


In  Standard  ML  the  notation  (h::t)  means  the  concatenation  of  the  head  and  tail  of  a 
list.  Completing  the  definition,  however,  does  not  provide  any  more  type  information 
for  length  and  we  are  left  with  Va./ista  —*  int  for  the  principal  type  of  length. 

We  propose  an  extension  of  W  for  on-line  type  checking.  (In  this  thesis 
type  checking  and  type  inference  are  used  synonymously.)  The  model  we  use  is 
a  consistently-attributed  parse  tree  specified  by  an  attribute-grammar.  Implicit  in 
the  model  is  incremental  recomputation  of  types.  In  addition,  recomputing  a  type 
can  be  reduced  to  reunification  using  a  well-known  reduction  from  Hindley-Milner 
style  type  checking  to  first-order  unification.  Unlike  other  extensions  of  W  [Ref.  13], 
for  on-line  type  checking,  our  on-line  type  checker  is  truly  incremental. 
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II.  THE  HINDLEY-MILNER  TYPE  SYSTEM 


In  this  chapter  we  review  the  history  and  basis  for  our  type  system.  In  Section  A 
we  describe  the  simply-typed  lambda  calculus.  In  Section  B  we  describe  the  Hindley- 
Milner  type  system  and  the  grammar  for  the  expressions  typed  in  their  type  system. 
U'e  will  also  describe  parametric  polymorphism  and  look  at  an  example  that  shows 
how  polymorphic  functions  are  useful.  In  Section  C  we  look  at  the  type  inference 
rules  of  the  Damas  and  Milner  type  system.  In  Section  D  ve  review  Damas  and 
Milner's  algorithm  W  which  infers  a  type  for  an  expression  of  the  grammar  given  in 
Section  B.  This  chapter  puts  the  thesis  contribution  in  the  context  of  other  work, 
namely  the  simply-typed  lambda  calculus,  the  Hindley-Milner  type  system,  and  the 
polymorphic  lambda  calculus. 

A.  THE  SIMPLY-TYPED  LAMBDA  CALCULUS 

The  simply-typed  lambda  calculus  has  types:  t  ::=  p  |  Tj  -+  Tj.  Small  greek 
letters  are  used  to  represent  type  variables  (type  variables  have  values  that  range  over 
all  named  and  anonymous  types  definable  in  a  language.)  We  will  use  the  standard 
notation  x  :  cr  to  mean  that  the  expression  x  has  type  (X.  In  this  type  system  we 
can  infer  the  types  of  lambda  expressions  such  as:  Ax.x  :  a  — ♦  a.  We  can  also  type 
more  complex  expressions  such  as:  (Ax.x)  Ax.x  :/?—>/?. 

In  the  simply-typed  lambda  calculus,  however,  we  would  be  unable  to  type  the 
expression,  {Xy.y  y)  Ax.x.  The  simply-typed  lambda  calculus  fails  to  infer  a  type  for 
this  expression  because  A  in  the  simply-typed  lambda  calculus  exhibits  monomorphic 
abstraction.  This  means  that  each  instance  of  y  in  {y  y)  must  have  the  same  type. 
In  order  to  type  {Xy.y  y)  Ax.x,  we  must  be  able  to  instantiate  a  unique  type  for 
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each  instance  of  y  in  {y  y).  The  simply-typed  lambda  calculus,  however,  fails  in 
this  regard.  But  the  expression  {Xy.y  y)Xx.x  reduces  to  the  equivalent  expression 
(\x.x)  Xx.x.  We  have  already  seen  that  this  expression  can  be  given  the  type  0  —*  3. 
So  we  have  two  expressions  that  are  equivalent  but  only  one  may  be  typed  in  the 
simply-typed  lambda  calculus. 

B.  HINDLEY-MILNER  TYPE  SYSTEM 

The  Hindley-Milner  type  system  extends  the  types  of  the  simply-typed  lambda 
calculus  with  type  schemes  (quantified  expressions  of  type  variables),  so  now  in 
addition  to  r  types  we  also  have  type  schemes.  The  complete  type  system  is: 

r  ::=  p  |  n  tj 
(T  ::=  Va.<r  |  r 

The  Hindley-Milner  type  system  is  able  to  infer  a  more  general  type  than  the  simply- 
typed  lambda  calculus.  In  the  Hindley-Milner  type  system,  for  example,  we  can  infer 
a  more  general  type  for  the  identity  function:  Ai.x  :  Va.a  —*■  a. 

The  Hindley-Milner  type  system,  however,  still  fails  to  infer  a  type  for  the 
expression  {Xy.y  y)  Xx.x,  because  of  the  limitation  of  monomorphic  lambda  abstrac¬ 
tion.  But  the  Hindley-Milner  type  system  provides  the  let  expression,  that  allows 
the  equivalent  expression:  let  y  =  Xx.x  in  y  y  ni,  to  be  correctly  typed.  Let  in  the 
Hindley-Milner  type  system  exhibits  polymorphism  and,  using  their  type  system,  we 
can  infer  the  correct  type:  Va.a  -+  a,  for  the  expression  let  y  =  Xx.x  in  y  y  ni. 
This  is  better  than  the  simply-typed  lambda  calculus  in  which  we  could  not  type  the 
expression  {Xy.y  y)Xx.x  at  all. 

In  order  to  type  the  expression  {Xy.y  y)  Xx.x  we  need  a  polymorphic  lambda 
calculus,  which  is  beyond  the  scope  of  this  thesis.  A  polymorphic  lambda  calculus 
is  a  second  order  calculus  that  would  allow  a  type  for  each  instance  of  y  in  (y  y)  to 
be  instantiated  uniquely. 
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e  —*  X 
I  e  e' 

I  Ax.c 

I  let  X  =  e  in  e'  ni 

Figure  2.1:  Expressions  in  the  Hindley-Milner  type  system. 

The  Hindley-Milner  type  system  will  infer  a  type  for  a  single  expression.  The 
grammar  for  expressions  in  the  Hindley-Milner  type  system,  shown  in  Figure  2.1,  is 
the  lambda  calculus  with  the  addition  of  let  expressions.  Some  authors  include  an 
additional  production  to  the  ones  given  in  Figure  2.1,  e  — >  c,  where  c  is  a  constant 
such  as  true,  false,  1,2,....  This  production  is  just  a  special  case  of  e  x  and  we 
will  use  just  the  production  e  —*  x  where  x  can  be  an  identifier  or  a  constant  such 
as  true,  false,  1,2,..,. 

Lambda  abstraction  Ax.x  is  the  identity  function.  By  definition,  this  function 
applied  to  any  argument  simply  returns  the  argument.  So  that  if  we  applied  Ax.x 
to  true  we  would  get  true,  and  if  we  applied  Ax.x  to  1  we  would  get  1.  In  the 
Hindley-Milner  type  system  we  are  able  to  infer  a  much  more  general  type  for  this 
expression.  We  can  now  say,  Ax.x  has  type  Va.a  — ►  a,  which  is  more  general  than 
/?  — » in  the  sense  that  a  can  be  instantiated  to  any  type. 

We  can  also  define  more  complicated  expressions  built  up  from  basic  expressions. 
For  instance,  we  can  define  a  function  first  =  Ax.Ay.x,  which  will  take  as  input  a 
pair  and  return  the  first  element  of  the  pair,  so  if  it  were  applied  to  (1  2)  it  would 
return  1.  Actually  the  lambda  calculus  is  curried,  which  means  functions  can  only 
be  applied  to  a  single  argument.  So  the  definition  we  have  given  for  first  actually 
takes  as  input  the  first  element  of  a  pair  and  returns  a  function  that  takes  as  input 
the  second  element  of  a  pair.  For  this  function,  the  value  returned  would  be  the  first 
element  of  the  two  input  elements. 
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Similarly  we  could  define  a  function  that  returns  the  second  element  of  a  pair: 
\x.\y.y,  which  will  take  as  input  a  pair  and  return  the  second  element  of  the  pair, 
so  if  it  were  applied  to  (1  2)  it  would  return  2. 

A  conditional  expression  can  similarly  be  defined: 

Cond  =  Xx.Xy.Xz.z  x  y, 

and  if  we  also  define  True  which  is  defined  the  same  «is  first, 

True  =  Xx.Xy.x, 

then  we  could  apply 

Cond  1  2  True, 

where  we  mean: 

{{{{Xx.Xy.Xz.z  X  y)  1)  2)  True). 

The  parentheses  have  been  added  to  emphasize  the  fact  that  the  lambda  calculus  is 
curried  and  the  X  abstraction  can  only  be  applied  to  one  argument.  The  order  in 
which  this  may  be  reduced  is: 

(((At/.Az.z  1  y)  2)  True), 

where  the  bound  occurrence  of  x  has  been  replaced  by  1.  Next  we  may  perform  the 
following  reduction: 

{{Xz.z  1  2)  True), 

where  y  has  been  replaced  by  2.  Finally  we  can  reduce  the  expression  to: 

{(True  1)  2), 

where  z  has  been  replaced  by  True.  This  can  also  be  reduced  as  follows: 

{(True  1)  2) 

=  (((Ax.Ay.x)  1)  2) 

-  ((Ay.l)  2) 

-»  1 
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This  reduction  gives  us  the  expected  result.  Recall  the  original  expression  was 
Cond  I  2  True.  If  this  were  expressed  as  the  equivalent  If  true  then  I  else  2  fi  we 
would  see  the  expected  result  immediately.  Since  true  is  always  true  we  get  1  from 
the  then  branch  of  the  conditional  expression  just  as  we  would  expect. 

Polymorphism  in  the  Hindley-Milner  type  system  is  called  parametric  polymor¬ 
phism.  Functions  that  operate  on  parameters  of  different  types  are  polymorphic. 
Suppose  that  we  could  define  a  function  length  that  returns  the  length  of  a  list  of 
any  type.  We  can  say  length  has  type  'ia.listot  int  adn  therefore  is  polymorphic. 
It  returns  the  length  of  any  list.  [Ref.  1 :  pg.  364] 

Aho,  Sethi,  and  Ullman  claim  Ada  is  polymorphic,  albeit  a  restricted  poly¬ 
morphism.  It  is  worth  taking  a  look  at  an  example  of  what  might  be  considered  a 
polymorphic  Ada  module.  Their  claim  is  that  generics  in  Ada  are  polymorphic.  In 
this  context  generic  is  an  Ada  reserved  word.  It  is  true  that  an  Ada  generic  module 
may  be  compiled  without  complete  type  specifications.  In  order  to  use  such  a  func¬ 
tion,  however,  the  generic  module  must  be  instantiated  at  run-tin»e.  The  generic 
module  must  be  instantiated  for  each  type  of  list  that  uses  the  function  length.  Thus 
at  run-time,  an  instance  of  the  generic  module  will  exist  for  every  type  for  which  the 
module  has  been  instantiated  and  each  module  will  be  monomorphic.  [Ref.  1 :  pg. 
364] 

Let’s  look  at  an  Ada  specification  for  a  generic  function  length,  that  will  return 
the  length  of  a  linked-list  of  any  type. 

generic 

type  list  is  private; 

with  function  Next  (e:  list)  return  list; 

with  function  Empty  (e:  list)  return  boolean; 
function  length  (1:  list)  return  positive; 
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We  must  also  provide  a  body  for  the  function. 

function  length  (1:  list)  return  positive  is 
len:  positive  :«  0; 

Iptr  :  list  :»  1; 
begin 

while  not  Empty (Iptr)  loop 
len  :*  len  +  1; 

Iptr  :*  Next (Iptr); 
end  loop; 
return  len; 
end  length; 

This  comprises  a  complete  compilation  unit  in  Ada.  A  bit  more  work  is  requirec 
to  use  the  function  length  in  a  program.  If  we  look  at  the  specification  for  the 
generic  function  we  see  that  three  parameters  are  required.  First,  we  must  know 
how  to  access  the  elements  of  the  list  so  we  need  a  pointer  to  a  list  element  which 
should  contain  a  field  with  a  pointer  to  another  list  element  and  to  be  useful  at  least 
one  data  field.  The  second  and  third  parameters  are  functions  which  are  required 
to  manipulate  the  type  of  list  we  have  specified  in  the  first  parameter.  Since  this 
is  a  generic  module  we  have  to  explicitly  provide  these  functions  when  the  generic 
function  is  instantiated  for  a  specific  list  type.  For  each  type  of  list  that  uses  the 
generic  function  length,  a  separate  instantiation  is  required.  Each  instantiation 
requires  separate  code  for  the  specific  list  type. 

At  compile  time  the  generic  function  length  could  be  given  type  ^a. list  a  -*  int 
that  leads  one  to  believe  generics  in  Ada  may  be  polymorphic.  At  run-time,  however, 
each  instance  of  length  can  only  have  type  list  r  — >  int  for  some  particular  r.  The 
fact  that  at  run-time  there  exists  an  instwce  of  the  function  length  for  every  type 
for  which  the  generic  function  length  has  been  instantiated  means  that  generics  in 
Ada  are  not  polymorphic,  and  in  fact  Ada  is  monomorphic. 

In  Standard  ML  a  function  that  finds  the  length  of  a  list  can  be  written  that  is 
polymorphic. 
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fun  length  1  ■ 
case  1  of 

□  ->  0 

I  (h::t)  ■>  1  +  (length  t) 

* 

Length  in  Standard  ML  could  also  be  typed  'ia.lista  —*  int  and  this  would  hold 
true  at  run-time  cis  well  [Ref.  1 :  pg.  365]. 

In  the  Hindley-Milner  grammar  the  let  expression  provides  let  polymorphism. 
If  e  is  polymorphic  then  in  the  expression  let  x  =  e  in  e'  ni,  every  free  occurrence  of 
X  in  e'  can  be  assigned  an  instance  of  the  type  of  e.  This  implies  that  each  occurrence 
of  X  in  e'  may  have  a  different  type  depending  on  how  each  occurrence  of  x  is  used 
in  e'. 

Different  strategies  have  been  proposed  for  typing  let  expressions.  Damas  and 
Milner’s  algorithm  W  handles  let  expressions  by  typing  the  definition  of  the  let- 
bound  id  and  then  typing  the  body  of  the  let  expression  in  an  environment  that 
includes  a  generic  type  for  the  /ef-bound  id.  Here  we  are  using  the  term  generic  to 
refer  to  a  type  that  may  be  instantiated  and  not  a  generic  unit  in  Ada.  See  [Ref.  4] 
for  more  about  generic  types. 

Another  strategy  is  to  replace  every  occurrence  of  the  /et-bound  id  in  the  body 
of  the  let  expression  with  the  definition  of  the  /et-bound  id.  This  strategy  has  a 
disadvantage.  If  the  /et-bound  id  does  not  occur  in  the  body  of  the  let  expression 
then  the  replacement  will  not  occur.  Consequently  during  type  analysis  the  definition 
of  the  /et-bound  id  will  never  be  processed.  This  would  allow  type  errors  in  the  body 
of  the  /ef-bound  id’s  definition  to  go  undetected.  This  is  unacceptable  under  strict 
semantics  for  let  expressions. 
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TAUT: 

A  h  X  :  <T 

X  :  <7  in  A 

INST: 

Ah  e  :  cr 

Ah  e  :  <r^ 

<T  >  cr' 

GEN: 

Ah  e  :  <r 

Ah  e  :  'iacT 

a  not  free  in  A 

COMB: 

ABS: 

LET: 

Figure  2.2:  The  Rules  of  the  Hindley-Milner  type  system. 

C.  THE  RULES  OF  DAMAS  AND  MILNER 

The  notation  used  in  this  paper  is  that  used  in  [Ref.  8].  Briefly,  A  is  a  set  of 
assumptions  for  which  the  following  holds  true:  A  contains  at  most  one  assumption 
about  each  identifier  x,  and  Ax  is  the  set  of  assumptions  with  no  assumption  for  x. 
We  use  the  notation  x  :  <r  to  mean  that  x  has  the  type  a.  Also  we  use  the  following 
notation  to  mean,  from  the  set  of  assumptions  A  we  can  infer  type  <t,  where  er  is  a 
type  scheme,  for  an  expression  e:  A  h  e  :  cr.  Also,  for  a  and  type  variables  and 
r  a  type  scheme:  [/Sj/cxjjT  means  to  replace  all  free  occurrences  of  the  q/s  in  r  with 
the  /Si's.  Damas  and  Milner  provided  the  rules  shown  in  Figure  2.2  for  type  inference 
[Ref.  8]. 
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D.  ALGORITHM  W 


Damas  and  Milner  gave  the  following  algorithm  for  typing  a  single  expression 
of  the  grammar  given  in  Figure  2.1  with  respect  to  an  initial  assumption  set  .4.  VV 
returns  a  substitution  S  and  a  type  variable  r  [Ref.  8]. 

\V{A.  e)  =  (S.  t)  where 

1.  If  e  is  j:  and  there  is  an  assumption  x  :  Vai...a„r'  in  .4  then  S  =  Id  and 
r  =  [J,/a,]r'  where  the  3,'s  are  new. 

2.  If  e  is  (ci  €2)  then  let  W(A,ei)  =  (5i.ri)  and  11^(51^, 62)  =  (52. r2)  and 
f  (52i'i,  T2  3)  =  V  where  3  is  new;  then  5  =  V'525i  and  t  =  V'J. 

■i.  If  c  is  Ax. Cl  then  let  3  be  a  new  type  variable  and  H''(.4i.Ux  :  J.fi)  =  (5i,r,); 
then  5  =  5i  and  t  =  Si3 

4.  If  e  is  let  x  -  ei  in  C2  ni,  then  let  W{A,  Cj)  =  (5i,ti)  and  W{A,  Cj)  =  (5i.  ti) 
and  VF(SiAiU{^  :  5ii4(ri)},  C2)  =  (52,  T2);  then  5  =  525i  and  r  =  T2. 

The  substitution  5  =  [/3i/Qj]  returned  by  W  must  be  applied  to  the  type  variable 
r,  and  the  resulting  r  type  must  closed  with  respect  to  the  initial  set  of  assumptions 
A.  The  result  is  a  type  scheme  for  the  expression. 

W  infers  the  type  for  a  single  expression.  There  is  no  implicit  mechanism  to 
deal  with  top-level  definitions.  Any  extension  of  to  a  “program”  must  be  done 
explicitly. 

1.  Most  General  Unifier 

Damas  and  Milner’s  algorithm  W  uses  Robinson’s  unification  algorithm. 
The  unification  algorithm  U  has  the  following  property:  If  U{t,  t')  returns  V,  then 
V  unifies  r  and  r',  i.e.,  Vt  =  Vr'.  Also,  if  5  unifies  t  and  t',  then  U{t,t')  returns 
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some  V  and  there  is  another  substitution  R  such  that  5  =  BV.  V  involves  only 
variables  in  r  and  r'  [Ref.  8:  pg.  210]. 

The  substitution  V  that  we  are  interested  in.  is  the  most  general  unifier, 
that  imposes  the  fewest  constraints  on  the  variables  in  the  expression  [Ref.  1 :  pg. 
370]. 

2.  Principle  Type  Scheme 

\V  infers  a  principal  type  scheme  for  an  expression.  This  implies  that 
any  other  type  scheme  for  the  expression  is  a  generic  instance  of  the  principal  type 
scheme.  This  is  dependent  on  the  unification  algorithm  returning  the  most  general 
unifier  [Ref.  8:  pg.  208]. 
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III.  ON-LINE  TYPE  INFERENCE  WITH 

UPDATE 


In  this  chapter  we  will  look  at  the  two  key  elements  of  a  type  checker  for  an 
interactive  programming  environment.  First,  we  look  at  what  makes  the  type  checker 
on-line.  .Second,  we  look  at  the  effect  of  an  update  which  affords  us  an  opportunity 
to  perform  type  checking  incrementally. 

Interactive  programming  environments  would  provide  much  greater  leverage 
to  the  programmer  if  the  environment  had  the  ability  to  perform  type  checking  as 
definitions  are  input  to  the  system,  one  definition  at  a  time,  rather  than  waiting 
until  a  series  of  definitions  is  complete  and  then  analyzing  them  for  type  errors. 
Additionally,  given  a  sequence  of  definitions  that  have  already  been  built  up  in  an 
interactive  environment,  a  small  change  to  one  definition  should  not  cause  the  entire 
sequence  to  be  retyped  unnecessarily.  If  the  system  is  well  designed  it  should  be  able 
to  use  <is  much  information  from  previous  typings  and  limit  recomputation. 

There  are  two  issues  involved.  The  first  is  what  we  refer  to  as  on-line  type 
inference.  Secondly,  we  are  concerned  with  the  semantics  of  what  an  update  to  a 
sequence  of  definitions  means  for  the  entire  sequence. 

Consider  defining  a  function  g  that  uses  a  function  /  such  that  g  is  free  in  E. 
If  we  encode  this  in  Standard  ML  using  let  as 

let  val  f  «  fn  ...  in 

let  val  g  «  fn  . . .f . . .  in  E 
end 
end 
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then  we  must  pay  attention  to  the  dependency.  The  definitions  of  /  and  g  are 
sequenced.  However.  Standard  ML  does  provide  simultaneous  declarations  so  we 
could  write  it  35  a  simultaneous  declaration  where  g  is  defined  first: 

fun  g()  *  . . .f 0  .  . . 
and  f 0  =  . .  .  ; 

E 

But  now  suppose  h  is  also  free  in  the  definition  of  g.  If  we  don't  include  a  definition 
for  h  as  well  in  the  simultaneous  declaration,  then  the  Standard  ML  interpreter 
complains  that  k  is  an  unbound  variable  or  constructor  when  in  fact  the  interpreter 
could  very  well  infer  a  type  for  /. 

The  problem  is  that  simultaneous  declarations  in  Standard  ML  and  letrec  defi¬ 
nitions  in  Scheme  are  typed  in  batch  mode.  That  is,  all  definitions  must  be  supplied 
before  a  type  is  inferred  for  any  one  of  the  defined  functions.  Clearly  this  is  unde¬ 
sirable  in  a  programming  environment  where  definitions  are  typically  given  in  any 
order  and  the  need  for  type  analysis  begins  before  all  definitions  of  objects  compris¬ 
ing  a  system  or  even  a  subsystem  are  present.  The  problem  at  hand  then  is  w’hat  we 
call  on-line  type  inference.  We  axe  proposing  a  programming  environment  in  which 
definitions  can  be  made  in  any  order  and  are  continuously  type-checked. 

A.  ON-LINE  TYPE  INFERENCE 

Type  checking  definitions,  one  at  a  time,  is  called  on-line  type  checking.  If  a 
definition,  g  has  been  provided  and  we  have  inferred  a  type  for  g,  then  when  we 
infer  a  type  for  /  in  which  g  occurs  free,  we  will  use  an  instantiation  of  the  type  of 
g  to  infer  a  type  for  /.  However,  if  no  definition  has  been  provided  for  g  and  we  are 
inferring  a  type  for  /  in  which  g  occurs  free  then  we  can  give  g  an  instantiation  of 
Va.a  as  necessary  in  /.  This  assumption  can  tzdce  place  without  restricting  the  type 
of  /  or  g,  nor  any  loss  of  generality.  This  implies  that  meaningful  type  analysis  may 
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take  place  at  any  time,  and  not  just  when  a  program  or  sequence  of  definitions  is 
complete.  This  also  means  that  if  g  occurs  more  than  once  in  /,  each  occurrence  may 
be  typed  uniquely  because  the  generic  type  Va.o  can  be  instantiated  as  necessary 
depending  on  how  g  is  used  in  /. 

We  propose  an  environment  that  will  infer  a  type  for  a  definition  that  may 
contain  free  identifiers  and  may  possibly  be  incomplete.  Those  free  identifiers  may 
be  defined  and  thus  may  have  an  associated  type.  In  the  caise  of  a  partial  definition 
missing  elements  will  be  represented  by  a  place  holder.  Thus  the  expression  will 
be  complete  in  the  context  where  place  holders  are  onsidered  valid  terms.  If  a 
definition  /  contains  free  identifiers  whose  types  are  not  known  or  is  incomplete,  we 
may  still  be  able  to  infer  a  type  for  /.  We  will  assume  that  an  undefined  identifier  has 
the  most  general  type  Va.a.  This  can  be  done  without  loss  of  generality,  restricting 
the  type  of  any  free  identifier  nor  imposing  any  constraints  on  the  type  of  a  term 
containing  place  holders.  If  /  contains  a  free  identifier  g  that  h«is  not  been  defined, 
a  type  may  still  be  inferred  for  /.  If  later  a  definition  is  provided  for  g,  then  the  type 
of  /  is  updated  reflecting  any  chjmges  imposed  by  the  type  of  g. 

We  could  extend  the  grammar  given  in  Chapter  II  for  expressions  to  include 
place  holders: 

e  — ►  <  expression  > 

I  * 

I  e  e' 

I  \x.e 

I  let  X  =  e  in  e'  ni 

The  production  e  —*  <  expression  >  denotes  a  place  holder  for  an  undefined  or 
partial  expression.  This  change  appears  minor,  but  if  we  allow  such  expressions  in 
the  grammar  and  are  still  able  to  infer  a  type  for  the  expression  then  we  can  infer 
types  for  partial  definitions. 

Recursive  definitions  are  handled  using  the  fixed  point  combinator  Y  [Ref.  2:  pg. 
164].  The  fixed  point  combinator  Y  has  the  property  that  for  an  expression  Af, 
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YM  —  M{Y M).  This  allows  recursive  and  mutually  recursive  definitions  to  be 
typed,  but  forces  the  user  to  use  the  fixed  point  combinator  Y . 

To  demonstrate  the  handling  of  mutual  recursion,  consider  defining  the  func¬ 
tions  even  and  odd.  Using  the  grammar  for  expressions  given  above  where  we  use 
the  notation  if  z  x  y  for  the  conditional,  we  first  define  a  function  pair: 

pair  =  \x.\y.\z.z  x  y 

.\ext  we  define  functions  first  and  second: 

first  =  Xx.Xy.x 
second  =  Xx.Xy.y 

Now  we  must  provide  a  definition  for  the  fixed  point  combinator  V': 

Y  =  Xf.{Xx.f{x  x)){Xx.f{x  x)) 

Y  ha.s  the  property  that  (YM)  for  some  function  M  is  M  {YM).  Finally,  we  must 
define  a  tuple  for  even  and  odd: 

P  =  (F(  Ax. ((pair 

(An. (if  (=  n  0)  true  ((x  second){  —  n  1))))) 

(An. (if  (=  n  0)  fake  ((x  first){  —  n  1))))))) 

Now  we  can  define  even  as  P  applied  to  first  and  odd  as  P  applied  to  second. 

even  =  {P  first) 
odd  =  {P  second) 
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Let’s  look  at  an  example:  First,  let’s  rewrite  P  to  make  it  easier  to  read 


P  =  [YM) 


where 

M  =  [Xx.{{pair 

(An. (if  (=  n  0)  true  ((x  second){  —  n  1))))) 

(An. (if  (=  n  0)  false  ((x  first)(  —  n  1)))))) 

Now  w’e  can  apply  even  to  a  number: 

(even  2) 

—  {{P  first)  2) 

first)  2) 

(((M  {YM))  first)  2) 
i{ii>^x.{{pair 

(An. (if  (=  n  0)  true  ((x  $econd){  —  n  1))))) 

(An. (if  (=  n  0)  fabe  ((x  first){  —  n  1)))))) 
{YM))  first)  2) 

-*  ((((po*r 

(An. (if  (=  n  0)  true  {{{YM)  second){  —  n  1))))) 
(An.(if  (=  n  0)  false  (((^M)  first){  -  n  1)))))) 
first)  2) 

—*■  ((An. (if  (=  n  0)  true  {{{YM)  second){  —  n  1))))  2) 

— ♦  {{{YM)  second)  1) 

— » {{{M{YM))  second)  1) 

((((^^•((pa*> 

(An.(if  (=  n  0)  true  ((z  second){  —  n  1))))) 

(An. (if  (=  n  0)  false  ((z  first){  —  n  1)))))) 
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(KM))  second)  1) 


((((pair 

(An. (if  (=  n  0)  true  {{{YM)  second){  —  n  1))))) 
(An.(if  (=  n  0)  false  {{{YM)  first){  -  n  1)))))) 
second)  1) 

^  ((An. (if  (=  n  0)  false  {{{Y M)  first){  —  n  1))))1) 

^  {{{YM)  first)  0) 

-.{{{M  {YM))  first)  0) 

—  (((('^^•((pa*> 

(An. (if  (=  n  0)  true  ((i  second){  —  n  1))))) 

(An. (if  (=  n  0)  false  ((x  first){  —  n  1)))))) 
{YM))  first)  0) 

((((pair 

(An. (if  (=  n  0)  true  {{{YM)  second){  —  n  1))))) 
(An. (if  (=  n  0)  false  {{{YM)  fir$t){  —  n  1)))))) 
first)  0) 

— »  ((An. (if  (=  n  0)  true  {{{YM)  second){  —  n  1))))  0) 

— >  {true) 


As  expected,  even  applied  to  2  returns  true. 

In  our  type  system  the  definitions  we  type  are  partially  ordered.  Ordered  defi¬ 
nitions  and  mutual  recursion  would  normally  cause  a  problem.  We  have  a  solution, 
however,  which  is  to  use  the  fixed  point  combinator  Y  and  tuples.  The  brief  exam¬ 
ple  we  just  looked  at  demonstrates  how  a  system  can  implement  mutually  recursive 
definitions  with  a  tuple  and  the  fixed  point  combinator  Y.  Since  we  can  define  mu¬ 
tually  recursive  definitions  using  a  tuple  and  Y,  the  definitions  given  in  a  program 
are  partially  ordered. 
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In  an  off-line  or  batch  type  system,  no  definition  may  contain  undefined  free 
identifiers,  otherwise  an  error  results.  Standard  ML  is  an  off-line  type  inference 
system.  In  our  system,  definitions  may  have  undefined  free  identifiers  and  the  order 
those  definitions  are  entered  is  irrelevant.  Additionally  a  definition  may  not  even  be 
complete  but  contain  place  holders  for  expressions  and  the  type  inference  system  will 
still  return  a  valid  type  if  one  exists.  Suppose  we  entered  the  following  definition; 

foo  =  A<  identifier  >  .  <  exp  >. 

The  place  holders  for  an  identifier  and  expression  indicate  we  have  not  completely 
specified  the  definition  of  foo,  however,  we  can  still  infer  a  type  for  foo:  Va.V,i.(Q  -+ 
J).  Type  analysis  takes  place  with  no  restrictions  imposed  by  the  place  holders  and 
we  can  infer  the  most  general  type  for  the  expression. 

Damas  and  Milner’s  algorithm  W  infers  a  type  for  a  single  expression.  We 
would  like  to  have  the  ability  to  type  a  series  of  named  expressions  or  a  ‘•program." 
A.  named  expression  is  simply  a  definition.  Typing  expressions  one  at  a  time  allows 
programs  to  be  develop  in  an  incremental  top-down  fashion.  This  is  not  so  easy  to 
do  in  batch  systems  since  a  free  identifier  for  which  no  definition  has  been  provided 
causes  an  error.  A  batch  system  forces  bottom- up  development  where  all  definitions 
must  be  defined  before  being  referenced.  For  example,  defining  g  and  then  /  in 
terms  of  g  should  be  the  same  as  defining  /  in  terms  of  g  and  then  defining  g.  In  an 
imperative  language  such  as  Ada,  if  we  define  /  in  terms  of  g  but  have  not  already 
defined  g,  nor  provided  a  specification  for  g,  during  compilation  we  will  get  an  error. 
Ada  requires  that  either  g  be  defined  or  a  specification  be  provided  prior  to  its  use. 
Either  way,  this  forces  the  programmer  to  worry  about  how  function  definitions  are 
ordered  when  in  fact  ordering  functions  at  the  same  nesting  depth  is  irrelevant  to 
the  meaning  of  the  program. 
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B.  UPDATE 


In  an  interactive  programming  environment  there  is  a  unique  problem  when 
we  have  a  sequence  of  definitions  and  we  update  or  modify  one  of  the  definitions. 
The  effects  of  an  update  varies  among  languages.  There  are  at  leeist  four  possible 
interpretations  for  updating  a  sequence  of  definitions  [Ref.  9]. 

1.  An  update  to  a  definition  supersedes  the  original  definition  and  is  used  in  all 
subsequent  references  to  the  definition  but  does  not  change  definitions  prior  to 
the  new  (updated)  definition.  This  is  ML’s  interpretation. 

2.  .An  update  to  a  definition  is  an  augment  to  a  partially  defined  definition  and  is 
incorporated  in  all  subsequent  references  to  the  definition  but  does  not  change 
definitions  prior  to  the  new  (updated)  definition. 

3.  An  update  to  a  definition  supersedes  the  original  definition  and  all  references 
both  prior  and  subsequent  to  the  new  (updated)  definition  are  changed.  This 
is  the  behavior  we  desire. 

4.  An  update  to  a  definition  augments  the  original  definition  and  all  references  to 
the  definition  both  prior  and  subsequent  to  the  new  (updated)  definition  are 
changed.  This  is  Prolog’s  interpretation. 

Standard  ML’s  interpretation  requires  that  the  user  re-enter  any  definition  that 
depends  on  the  modified  definition  if  the  effect  of  the  modification  should  be  propa¬ 
gated.  For  example,  in  Standard  ML  if  we  have  a  definition  /  and  then  a  definition 
g  which  references  /,  and  then  update  the  definition  of  /  so  now  we  have  /',  the 
reference  to  f  in  g  is  not  changed,  and  consequently  g  is  not  changed  either.  This  is 
not  desirable  because  if  there  are  many  other  definitions  besides  g  which  reference  / 
and  we  want  them  all  to  refer  to  the  new  definition  /',  then  every  d' ''  ition  in  which 
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/  occurs  free  that  we  want  to  reference  the  new  definition  f  must  be  re-entered 
after  the  new  definition  for  /'.  A  better  solution  would  be  to  have  an  environment 
that  allows  a  user  “to  go  back”  and  modify  the  original  definition.  In  this  sense  a 
syntax-directed  editor  provides  the  logical  framework  in  which  to  allow  updates  to 
be  made  directly  to  the  original  text.  Update  will  now  replace  the  original  definition 
and  all  references  to  the  definition  will  refer  to  the  new  definition. 

Typically  for  environments  like  Prolog,  Scheme,  and  Standard  ML  a  file  is 
loaded  and  the  entire  file  is  interpreted  and  any  type  errors  are  reported  at  that 
time.  If  a  definition  is  to  be  changed  then  the  file  is  edited,  loaded,  and  processed. 
So  even  if  the  change  was  small  and,  only  a  few  definitions  needed  to  be  processed, 
the  rest  of  the  definitions  in  the  file  are  processed  unnecessarily.  The  problem  is  how 
to  handle  small  changes  to  a  large  set  of  definitions  with  the  minimum  amount  of 
work  [Ref.  10]. 

There  are  two  issues  that  determine  the  incremental  aspects  of  an  update.  First, 
if  we  can  preserve  information  when  we  type  a  definition  we  can  reduce  the  amount 
of  work  that  is  necessary  to  recompute  the  type  of  that  definition.  Assume  we  have 
a  definition  /  in  which  g  occurs  free.  A  type  may  already  have  been  inferred  for  / 
when  a  modification  to  g  necessitates  that  /  have  its  type  reinferred.  If  we  use  ais 
much  information  as  possible  from  the  earlier  typing  of  /  when  its  type  is  reinferred 
then  we  can  type  /  incrementally. 

Second,  if  the  dependencies  are  carefully  observed  only  those  definitions  that 
depend  on  a  modified  definition  or  whose  type  changes  as  a  result  of  a  modification, 
must  be  retyped.  It  is  possible  to  partially  order  the  definitions  because  we  have  the 
fixed  point  combinator  Y  to  handle  recursive  and  mutually  recursive  definitions.  We 
can  represent  the  dependencies  as  a  pair  {f,g),  that  means  /  depends  on  g.  If  we 
have  a  sequence  of  definitions  with  the  following  dependencies,  {{f,g),  (/,  h),  {h,  t)} 
and  /  were  modified,  only  /  would  need  to  have  its  type  inferred.  If  i  were  modified 
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then  types  would  need  to  be  inferred  for  /,  k,  and  t,  but  not  g.  So,  by  observing  the 
dependencies  we  can  limit  the  amount  of  work  needed  to  infer  types  for  the  sequence 
of  definitions. 

Since  we  have  an  environment  that  allows  the  programmer  to  edit  the  original 
definition  there  is  no  question  what  a  reference  to  a  modified  definition  should  be. 
The  original  definition  no  longer  exists  so  any  reference  must  be  to  the  new  updated 
definition.  This  is  even  more  important  in  an  on-line  environment  where  definitions 
may  be  entered  in  any  order.  In  /  a  reference  to  g  may  refer  to  a  definition  either 
above  or  below  /  in  the  parse  tree.  The  ordering  does  not  matter  in  the  on-line 
environment.  So  if  /  references  g  and  g  is  modified  yielding  g'  the  reference  in  /  is 
clearly  to  g'. 
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IV.  ON-LINE  TYPE  INFERENCE  THROUGH 

ATTRIBUTION 


In  this  chapter  we  look  at  a  special  class  of  grammars  called  attribute  grammars 
and  provide  an  attributed  grammar  for  on-line  type  inference.  The  attribution  is 
circular  but  nonetheless  is  an  on-line  type  inference  algorithm.  In  Section  A  we 
look  at  attribute  grammars  in  general  and  provide  the  semantics  for  the  attribute 
equations  of  an  attributed  grammar.  In  Section  B  we  will  look  at  a  circular  set  of 
attribute  equations  for  on-line  type  inference  and  discuss  the  meaning  of  such  a  set 
of  attributi  equations. 

A.  ATTRIBUTE  GRAMMARS 

A  context-free  grammar  (CFG)  is  a  tuple,  G  =  (N, S,S,  P)  where  N  is  &  set 
of  symbols,  E  is  a  set  of  terminals,  5  6  is  the  start  symbol,  and  P  is  a  set 
of  productions.  This  formalization  can  be  easily  extended  to  allow  the  symbols  in 
(.V IJ  E)  to  have  values.  This  extension  is  a  special  claiss  of  grammars  called  Attribute 
Grammars  (AGs).  The  names  of  values  associated  with  a  symbol  in  a  grammar 
are  called  attributes.  The  attributes  for  a  grammar’s  symbols  can  be  divided  into 
two  categories:  inherited  and  synthesized.  Inherited  attributes  can  be  calculated 
from  parent’s  and  sibling’s  attributes.  Synthesized  attributes  can  be  calculated  from 
children’s  attributes  and  other  attributes  at  the  same  node.  The  equations  from 
which  an  attribute's  value  is  determined  are  called  attribute  equations.  [Ref.  1 :  pg. 
280] 

Formally,  an  attribute  grammar  can  be  expressed  as  a  5-tuple  [Ref.  7): 

AG  =  {G,  A,  VAL  SD,  SC). 
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G  is  a  context-free  grammar  that  we  just  discussed.  A  is  a  set  of  attributes  such 
that  each  attribute  a  €  A  ranges  over  a  domain  of  values  denoted  by  Dom{a).  VAL 
is  the  set  of  values  that  an  attribute  a  can  assume, 

VAL  =  {Z)om(a)  |  a  €  A}. 

Each  attribute  is  associated  with  a  symbol  of  (iVyS).  If  X  is  a  symbol  of  G  then 
the  attributes  of  X  are  denoted  by: 

A*  =  {X.a  1  a  €  A}. 

For  each  occurrence  X,  of  a  symbol  in  a  production  p  there  is  an  attribute  instance 
X,.a  for  all  a  €  A^.  For  each  production  p,  the  set  of  all  attribute  instances  is: 

Ap  =  [Xi.a  1  a  €  Ai  and  Xi  €  p}. 

A  is  partitioned  into  two  disjoint  sets  AI  and  AS,  the  inherited  and  synthesized 
attributes  respectively.  The  inherited  attributes  of  the  start  symbol  must  be  null, 
AIs  —  0-  The  synthesized  attributes  of  the  terminal  symbols  must  also  be  null, 
A5x  =  0  if  XeE. 

SD  is  the  set  of  semantic  definitions  for  the  productions  of  P. 

SD  =  {SDp\p€P}. 

A  semantic  definition  defines  the  value  of  an  attribute  instance  in  Ap.  The  value 
depends  only  on  other  attribute  instances  in  Ap.  There  can  be  only  one  such  semantic 
definition  that  assigns  a  value  to  an  attribute  a  in  Ap.  Given  a  semantic  definition 
/  :  Z)om(5o)  x  •  •  •  x  Dom(hk)  -+  Dom{a),  then  {Xi.a  =  /{Xo.bo, .  ..,Xk.bk))  €  SDp. 
Thus,  semantic  definitions  are  local  to  a  particular  production  p  €  P. 

SC  is  the  set  of  semantic  conditions  (predicates).  There  is  one  semantic  condi¬ 
tion  for  each  production  p  E  P. 

SCp  G  Dom{bo)  x  •  •  •  x  Dom{bk)  BOOL,  bj  €  Ap. 
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E  -*  E  +  F 
1  E-F 
I  F 
F  -  : 


Figure  4.1:  Productions  for  the  calculator  grammar. 


Production  Semantic  Rules 


E-*  E  +  F 
E-*  E-F 
E-*  F 
F-*i 


Ei.v  =  E2-V  +  F.v 
E\.v  =  E^.v  —  F.v 

E. v  =  F.v 

F. v  =  i.lexval 


Figure  4.2:  Semantic  definitions  for  the  productions  in  Figure  4.1. 

A  sentence  5  in  L{G)  is  in  L{AG)  iff  for  each  use  of  production  p  in  a  derivation  of 
5,  the  values  of  its  attribute  instances  satisfy  SCp. 

Consider  the  following  grammar  G,  where  N  =  {£,  F},  S  =  i.  S  =  E,  and  the 
set  of  productions  P  is  given  in  Figure  4.1.  The  grammar  defines  a  calculator  for 
the  +  and  —  operators.  This  CFG  can  be  attributed  so  that  we  have  an  attributed 
grammar  AG.  First,  we  let  the  set  of  attributes  for  E  and  F  be  {u},  so  A  =  {i;}. 
The  domain  for  v  is  the  natural  numbers  so  VAL  =  Z.  The  semantic  definitions 
are  given  in  Figure  4.2.  In  Figure  4.2  the  notation  E\  refers  to  the  first  or  leftmost 
occurrence  of  the  symbol  E  in  the  production.  Multiple  occurrences  are  counted  left 
to  right.  For  example,  E\.v  refers  to  the  attribute  named  v  of  the  first  symbol  E  in 
a  production.  If  a  term  E  occurs  only  once  in  a  production  its  attributes  are  simply- 
denoted  E.a. 

The  parse  tree  for  this  grammar  can  then  be  decorated  with  the  value  of  the 
expressions  such  that  at  each  node  we  store  the  value  of  the  subtree  rooted  at  that 
node.  For  example,  the  decorated  parse  tree  for  the  expression  3  +  7  is  given  in 
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^(10) 


Figure  4.3;  Attributed  parse  tree  for  the  expression  3  +  7. 

Figure  4.3.  [Ref.  1 :  pg.  280] 

B.  A  CIRCULAR  ATTRIBUTION  FOR  ON-LINE  TYPE 
INFERENCE 

A  special  case  of  an  AG  is  a  circular  AG  (CAG).  Non-circular  AGs  (NCAGs) 
have  been  found  useful  in  a  variety  of  applications.  CAGs,  however,  have  generally 
not  been  considered  useful,  and  in  fact  were  considered  ill-formed  and  meaningless 
until  recently  [Ref.  1 ;  pg.  334]  and  [Ref.  12].  Semantic  equations,  for  a  circular 
attribution,  that  employ  monotonic  operators  (over  some  complete  partial  order), 
define  a  unique  greatest  (least)  fixed  point  that  may  be  interpreted  as  the  meaning 
of  the  circular  attribution  [Ref.  12].  Sagiv  et  al.  also  give  an  algorithm  for  converting 
these  CAGs  to  NCAGs  [Ref.  12]. 

On-line  type  inference  can  be  characterized  as  computing  the  least  fixed  point 
of  a  set  of  circular  attribute  equations.  We  will  provide  a  CAG  that  is  an  on-line  type 
inference  algorithm.  The  CFG  for  the  language  used  in  our  type  inference  system  is 
similar  to  the  grammar  used  in  Hindley-Milner  style  type  system. 

A  set  of  attribute  equations  is  circular  if  there  is  a  mutual  dependency  between 
two  attributes.  When  an  attribute  S.i  depends  on  an  attribute  S.a  and  S.a  depends 
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T  P 
P  D  P\D 
D  -»  Id  =  M 
M  ^  Id 
I  M  N 
1  Xld.N 

I  let  Id  =  M  in  Nni 


Figure  4.4:  CFG  for  the  on-line  type  inference  system. 


Production  Semantic  Definitions 

r  P  P.inhTE  =  0 

P  —*  D  P  P\.synTE  =  D.synTE\JP2.synTE 

Pi.inhTE  =  D.synTE 
D.inhTE  =  P\.inhTE\JP2-synTE 
P^D  D.inhTE  =  P.inhTE 

P.synTE  =  D.synTE 

D-^  Id  =  M  D.synTE  =  {Id,  TypeOf{M,  D.inhTE)}  (J  D.inhTE 

Figure  4.5:  Semantic  definitions  for  the  grammar  in  Figure  4.4. 

on  S.i,  where  i  is  an  inherited  attribute  and  a  is  synthesized,  the  AG  is  circular. 

The  CFG  we  will  use  for  the  on-line  type  inference  problem  is  given  in  Figure  4.4. 
The  set  of  attributes  for  this  grammar  is  A  =  {inhTE,synTE}.  The  domain  of  the 
attributes  in  A  are  type  environments  ordered  by  subset  inclusion.  The  semantic 
definitions  for  the  CAG  are  given  in  Figure  4.5.  There  are  no  semantic  conditions 
for  this  CAG,  so  SC  =  0. 

The  inherited  and  synthesized  type  environment  attributes  in  A  denoted  by 
inhTE  and  synTE  respectively  are  used  to  pass  the  inferred  type  environment  up 
and  down  the  tree.  A  type  environment  maps  id’s  to  type  schemes.  At  the  node 
for  each  definition  a  type  will  be  inferred  and  then  added  to  the  type  environments 
being  passed  up  the  tree  and  down  the  tree.  The  attribute  equations  for  the  pro- 
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Figure  4.6:  A  cirralai  attribution  for  on-line  type  inference. 

duction  P  —*  D  P  add  the  type  of  a  definition  to  the  inherited  and  synthesized  type 
environment  attributes  for  the  symbol  P. 

The  type  environment  that  is  inherited  at  a  node  D  in  the  production  P  D  P, 
consists  of  the  types  of  all  the  definitions  both  above  and  below  the  node  in  the  parse 
tree.  These  types  are  propagated  up  the  tree  in  P’s  synthesized  type  environment 
attribute  and  down  the  tree  in  P’s  inherited  type  environment  attribute. 

In  the  attribute  equation  for  the  production  D  —*  Id  =  M,  the  function  TypeOf 
returns  the  principal  type  of  the  expression  M  with  respect  to  the  inherited  type 
environment  D.inhTE.  The  circularity  of  this  attribution  is  shown  in  Figure  4.6. 

A  trivial  program  in  this  language  might  look  like: 

a  =  Ax.x; 
b  =  a; 

The  parse  tree  for  this  program  is  shown  in  Figure  4.7.  The  attribute  equations  for 
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Figure  4.7:  The  parse  tree  for  a  =  \x.x  and  b  =  a. 


the  program  shown  in  Figure  4.7  yield  the  system  of  equations  in  Figure  4.8.  The 
least  fixed  point  of  a  circular  set  of  attribute  equations  such  as  the  ones  in  Figure  4.8 
is  a  solution  to  the  on-line  type  inference  problem. 

A  CAG  is  meaningful  if  a  few  conditions  are  met.  By  Tarski’s  theorem  if  a 
system  5  is  such  that  all  the  functions  /,  are  monotonic  in  all  their  arguments, 
and  all  functions  are  defined  over  complete  partial  orders  (CPOs)  then  a  fixed  point 
exists  [Ref.  12:  pg.  38].  Unlike  Sagiv  et  al.  we’re  interested  in  the  least  fixed  point. 

The  system  of  equations  in  Figure  4.8  can  be  shown  to  meet  Tarski’s  conditions, 
eis  discussed  in  Sagiv’s  et  al.’s  work,  and  thus  has  a  least  fixed  point,  which  is  a  type 
environment  providing  types  for  all  definitions  whose  types  can  be  determined  in  the 
input  stream.  The  right  hand  sides  of  the  equations  in  Figure  4.8  can  be  viewed 
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vi.inhTE  = 

0 

(4.1) 

Vi-synTE  = 

v^.synTE  (J  v^.synTE 

(4.2) 

Vi.inhTE  = 

v\.inhTE  (J  v^.synTE 

(4.3) 

V2.synTE  = 

{a, a  — »  o)  ij  vj.inhTE 

(4.4) 

Vi.inhTE  = 

v^.synTE 

(4.5) 

vs.synTE  = 

V4.synTE 

(4.6) 

V4.inhTE  = 

vz.inhTE 

(4.7) 

V4.synTE  = 

if  (a,  r)  €  V4.inhTE  rmthen 
{b^TypeOf(a,A,V4.inhTE))  (J  V4.inhTE 
else  V4.inhTE 

(4.8) 

Vi.inhTE  =  v^.synTE 

Figure  4.8:  Semantic  equations  for  program  in  Figure  4,7 

(4.9) 

as  functions  that  compute  the  value  of  the  attribute  given  in  the  left  hand  side  of 
the  equations.  Equation  4.1  is  trivially  monotonic  because  0  is  a  constant  function. 
Equations  4.2-4.4  are  monotonic  since,  Vi.Vy.Vz.  x  C  y  ^  x\Jz  C  y\Jz  therefore 
the  union  operator  U>  is  monotonic  in  both  its  arguments.  Equations  4. 5-4.7  and 
4.9  are  implicitly  defined  using  identity  which  is  monotonic.  To  show  Equation  4.8, 
denoted  is  monotonic  we  must  show  that  Vx.Vy.  z  C  y=>  /i.8(x)  C 

Suppose  X  C  y.  Then 

Case  I.  If  (a,  t)  €  x  =»  =  xU{(^?  ■’')},  since  x  C  y  then  (a,T)  €  y  ^ 

/4.8(y)  =  yU{(^-r)} 

Case  II.  If  (a,r)  ^  x  =»  f4.s{x)  =  x.  If  (a,T)  6  y  then  /4.8(y)  =  yU{(^7’)}»  and 
if  (a,  t)  ^  y  then  f4.s{y)  =  y-  In  either  of  these  two  cases,  f4.B{x)  C  f4.s{y). 

The  domain  of  the  equations  in  Figure  4.8  is  the  power  set  of  the  set  of  all  typed 
definitions.  If  our  program  consists  of  definitions  for  a  and  6,  then  the  powerset 
of  typed  definitions  consists  of  {0,{(a, ra)},{(6, Tii)},{(a, ra),(6, ri,)}}  which  can  be 
ordered  by  sec  inclusion.  The  resulting  ordering  is  a  CPO  shown  in  Figure  4.9. 
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{Kr,),  (6,Ti)} 


0 


Figure  4.9:  Type  environments  ordered  by  set  inclusion. 

We  are  concerned  with  the  least  fixed  point.  If  {(a, a  — »  a),  (6, a  — »  o)}  is 
a  solution  to  the  type  inference  problem  for  the  program  a  =  Xx.x:  b  =  a;  then 
{(a, a  — .  a),  {b,a  -*  q),  (c, q  — ♦  q)}  is  also  a  solution,  meaning  it  is  also  a  fixed 
point  but  it  is  not  the  least  fixed  point.  The  set  {(o,  a  -♦  a),  {b,a  o)}  is  the 
least  fixed  point  for  the  semantic  definitions  of  the  program  in  Figure  4.7. 

While  we  know  that  the  circular  attribution  given  in  Figure  4.5  has  meaning 
and  can  be  shown  to  have  a  least  fixed  point  which  can  be  taken  to  be  a  solution 
to  the  type  inference  problem,  tools  exist  for  NCAGs.  Sagiv  et  al.  have  a  technique 
for  transforming  CAGs  to  NCAGs  [Ref.  12].  This  transformation  from  a  circular 
attribution  to  a  non-circular  attribution  is  being  investigated. 

Another,  alternative  would  be  to  use  Farrow’s  evaluator  generator  which  is  capa¬ 
ble  of  accepting  a  circular  attribution  and  generating  a  fixed-point-finding  attribute 
evaluator.  [Ref.  5] 
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V.  AN  INCREMENTAL  ALGORITHM  FOR 
ON-LINE  TYPE  INFERENCE 


In  this  chapter  we  present  an  incremental  algorithm  for  on-line  type  inference 
that  is  an  incremental  type-checker.  It  is  a  syntax  directed  editor,  but  can  be  thought 
of  as  a  programming  environment.  As  such,  it  provides  the  programmer  an  envi¬ 
ronment  to  evaluate  the  types  for  definitions  of  the  form  val  i  =  e,  where  val  is  a 
keyword  to  denote  a  definition.  Identifiers  i,  denote  the  name  of  the  definition.  The 
expressions,  denoted  by  e,  have  the  form  we  saw  in  Chapter  IV.  The  definitions  all 
have  top-level  scope  much  like  definitions  in  Standard  ML.  Unlike  Standard  ML. 
ho  '  ever,  the  scope  of  the  definitions  in  our  programming  environment  is  the  entire 
prog:  am  and  not  only  the  rest  of  the  program  that  appears  after  the  definition. 
Moreover,  the  order  'Jefinitions  are  entered  is  irrelevant. 

First,  we  look  at  an  incremental  algorithm  for  on-line  type  inference.  It  relies 
on  a  reduction  from  the  Hindley-Milner  type  system  to  first-order  unification.  The 
remainder  of  the  chapter  is  devoted  to  an  example  that  demonstrates  the  reduction, 
unification  and  resulting  type  computations. 

A.  THE  INCREMENTAL  ALGORITHM 

The  algorithm  is  incremental  in  two  respects.  First,  if  the  type  of  a  definition 
must  be  reinferred  as  much  work  as  possible  from  the  previous  typing  is  used  in  the 
retyping.  Second,  only  those  definitions  whose  types  may  have  changed  will  have 
types  reinferred.  There  are  three  events  that  may  cause  a  definition’s  type  to  change. 
First,  when  a  definition  is  input  to  the  system.  Second,  when  a  definition  is  modified. 
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Figure  5.1:  Dependency  partial  order. 

Third,  when  a  definition’s  type  changes  as  a  result  of  a  change  to  the  type  of  another 
definition  on  which  it  depends. 

If  a  definition  /  must  be  retyped  as  a  result  of  a  new  type  being  generated  for 
a  definition  g,  that  occurs  free  in  /,  we  can  retype  /  incrementally  if  we  can  use 
some  information  from  the  original  computation  for  the  type  of  /.  If  we  observe  the 
dependencies  we  can  be  even  more  incremental.  For  example,  if  we  have  definitions 
/,  g,  h,  i,  and  dependencies  {(/,</),(/,  A),  (A,  *)},  shown  in  Figure  5.1,  where  (f,g) 
means  /  depends  on  g,  and  then  modify  the  definition  of  t,  we  must  infer  a  new  type 
for  i,  since  it  was  modified.  In  addition,  if  the  type  of  i  changes,  we  will  have  to  infer 
new  types  for  those  definitions  that  depend  on  i.  But  we  have  to  be  careful  about 
the  order  in  which  the  definitions  are  typed  after  I’s  type  is  reinferred.  If  we  modify 
the  initial  set  of  definitions  such  that  i  is  free  in  both  h  and  j,  then  we  have  the 
dependencies  shown  in  Figure  5.2.  Both  h  and  j  depend  on  t,  but  j  also  depends  on 
h.  If  i  is  modified  then  we  may  need  to  infer  types  for  /,  ft,  and  j,  but  we  must  type 
ft  before  /  and  j  because  of  the  dependencies  (j,  ft)  and  (/,  ft).  If  we  recompute  ft’s 
type  and  it  does  not  change  then  only  j  remains  to  be  typed,  not  /,  even  though  / 
transitively  depends  on  i,  which  was  modified. 

Before  we  give  the  incremental  algorithm  we  must  first  define  some  notation. 
Let  i4  be  a  set  of  type  assumptions  mapping  the  given  operators  to  type  schemes. 
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Figure  5.2:  Direct  and  transitive  dependency  for 

The  operators  in  the  initial  assumption  set  are  cons,  hd,  tl,  nil,  and  Y.  Let  G  (a 
DAG)  be  the  dependency  graph  for  the  definitions  in  the  program.  Let  eqn]^  and 
am  denote  the  type  equations  and  the  type  variable  respectively,  for  a  term  M. 
Construction  of  tqnj^f  and  om  is  discussed  in  Section  B.  We  also  let  TE[v'  :  a] 
mean  update  type  environment  TE,  so  that  u'  now  has  type  <t.  The  algorithm  uses 
function  TypeOf  defined  by 

TypeOf{M,  TE)  =  let  S  =  Unijy{tqnj^,  TE)  in 
close{Sa\f,  TE). 

Unify  needs  a  type  environment  since,  as  we  shall  see,  eqnj^f  may  contain  references 
to  types  of  other  top-level  definitions.  TypeOf  applies  the  most  general  unifier  of 
eqn^,  lo  qm  and  then  closes  the  resulting  type  giving  the  principal  type  for  M. 
The  incremental  algorithm  is  defined  below: 

Input:  A  DAG  G  of  definitions,  a  type  environment  TE  and  a  vertex  v  of  G. 

Output:  A  type  environment. 

begin 

Affected  =  {u} 
while  Affected  ^  0  do 

delete  the  least  element  v'  €  Affected 
let  <T  =  TypeOf  {M,  TE)  where  v*  is  defined  as  term  M  in 
if  <T  a'  where  u' :  <r'  €  TE  then 

Affected  =  Affected  \J{x  \  (x,  u')  6  edges{G)} 
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TE  =  TE[v' :  <t] 
fi 
ni 
od 

return  TE 
end 

Let  R  be  the  dependency  relation  for  a  set  of  definitions  5.  We  must  compute 
the  transitive  closure  of  the  dependency  relation  R.  The  transitive  closure  is  anti¬ 
symmetric  by  virtue  of  the  way  mutual  recursion  is  handled  using  the  fixed  point 
combinator  Y.  Therefore  the  transitive  closure  is  antisymmetric  and  transitive,  and 
thus  a  partial  order  say  P.  We  can  extend  P  to  a  consistent  total  (linear)  order  L.  We 
write  the  dependency  (x,m)  as  m  <  x.  For  a  modified  definition  m  let  Affected{m) 
be  the  set  of  affected  definitions.  Affected{m)  C  5,  is  defined  as  {x  |  (x,m)  €  P}. 
So  Affected{m)  is  the  set  of  all  definitions  that  depend  on  the  modified  definition 
m.  The  Affected  set  is  totally  ordered  by  L,  so  we  can  recompute  the  types  of  each 
definition  in  Affected  in  the  order  given  by  L. 

We  can  take  the  example  from  Figure  5.2  and  again  consider  what  happens  if 
i  is  modified.  A  total  (linear)  order  for  this  set  of  definitions  is  L  =  {g,i,h,j^f). 
W’hen  the  incremental  algorithm  is  called.  Affected  is  set  to  i.  Since  i  is  the  only 
element  in  Affected  it  is  the  least  element  and  is  removed  from  Affected.  The  type 
of  i  is  computed  and  we  will  assume  the  type  has  changed  from  the  previous  type  of 
i.  Affected  is  updated  to  include  h  and  j.  The  type  environment  TE  is  also  updated 
with  the  new  type  for  i.  On  the  next  iteration,  Affected  is  {h,j}  and  since  h  <  j, 
h  is  the  next  definition  to  be  retyped.  If  the  type  of  h  has  changed,  then  /  would 
be  added  to  the  Affected  set,  otherwise  only  j's  type  remains  to  be  computed.  This 
process  continues  until  Affected  is  empty. 
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E{M,A)  = 

case  M  of 

\x.M  :  let  A*  =  0  new  var  in 

let  (a,c)  =  E{M,A')  in 

(li  {®}  U{7  0  —*  o})  where  7  is  new 


{M  N):  let  (a,  ci)  =  E{M, ^1)  in 

let  (0,62)  =  E{N,A)  in 

(7>{ci}U{c2}U{Q'  =  0  new 


x: 


if  X  :  Vd.r  G  A  then 

let  r'  =  [0i/ai]T  where  0i's  are  new  in 
i'fi  =  7})  where  7  is  new 

else 

(/3,  {t,  =  0})  0  new 


Figure  5.3:  Algorithm  E,  to  generate  the  type  equations  for  an  expression. 

B.  REDUCTION 

Note  that  TypeOf  uses  and  eqtiM  produced  for  a  term  M.  The  latter  is  a 
set  of  type  equations  corresponding  to  an  instance  of  first-order  unification.  This 
instance  is  obtained  by  a  well-known  reduction  from  type  inference  to  unification 
[Ref.  14].  The  ojv/  is  a  type  variable  to  which  the  most  general  unifier  can  be  applied 
to  get  a  principal  type  for  M.  The  reduction  is  achieved  by  algorithm  E  of  Figure  5.3. 
It  takes  a  term  M  and  an  assumption  set  A  &s  input  and  returns  a  pair  [om,  tqnj^), 
where  qm  is  a  type  variable  and  tqUf^  is  an  associated  set  of  type  equations  for  M . 
The  type  obtained  by  closing  the  application  of  equj^f's  most  general  unifier  to  aj^f 
is  the  principal  type  of  M. 

The  notation  tx  means  the  type  of  the  definition  for  i.  In  £  we  generate  type 
equations  where  tx  stands  for  the  type  of  x.  When  we  unify  the  equations  for  a 
definition  say  y  in  which  x  occurs  free  we  must  instantiate  the  type  of  x  and  replace 
each  occurrence  of  tx  in  the  type  equations  for  y  with  an  instantiation  of  the  type 
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of  X.  Since  the  definitions  will  be  p&rti&lly  ordered  we  know  we  will  have  already 
typed  the  definition  for  x  prior  to  typing  the  definition  for  y  if  x  occurs  free  in  y, 
thus  we  will  be  able  to  instantiate  the  type  of  x  for  each  occurrence  of  in  the  type 
equations  of  any  definition  y.  each  occurrence  getting  a  new  instantiation. 

The  correctness  of  algorithm  E  can  be  stated  as  follows;  Suppose  E{M,A)  = 
(om>  where  M  is  a  let-free  expression,  is  a  set  of  type  assumptions,  om  is 

a  type  variable,  and  eqnj^  is  a  set  of  type  equations.  Then  5  is  a  unifier  of 
A  h  M  :  SoM. 

1.  Algorithm  L  -  Lifting  Let  Expressions 

To  build  the  type  equations  necessary  for  unification  we  must  first  deal 
with  let  expressions.  Algorithm  E  does  not  handle  let  expressions.  The  system 
proposed  by  Wand  and  O’Keefe  also  ignores  let  expressions  [Ref.  14].  Cardelli’s 
system  handles  let  expressions  in  the  same  fashion  as  Damas  and  Milner  [Ref.  4] 
[Ref.  8).  Their  strategy,  however,  is  not  suitable  for  an  on-line  environment.  Typing 
the  /e<-bound  id’s  definition  and  then  typing  the  body  of  the  let  expression  will  not 
work  in  an  environment  with  top-level  definitions,  because  a  /cf-bound  id's  definition 
may  contain  free  identifiers.  To  meet  the  requirements  for  being  on-line,  a  /c/- bound 
id’s  definition  would  have  to  be  partially  ordered,  along  with  the  rest  of  the  top  level 
definitions  and  typed  accordingly. 

In  order  to  handle  let  expressions  we  need  a  different  strategy.  To  construct 
the  equations  necessary  for  unification,  we  must  lift  the  let  expressions  from  the  terms 
of  our  programs  so  that  all  our  expressions  are  /e<-free. 

There  are  two  considerations  that  determine  how  let  expressions  must  be 
handled.  First,  we  require  let  expressions  to  exhibit  polymorphism.  This  requirement 
implies  that  each  occurrence  of  a  /et-bound  id  in  the  body  of  the  let  expression  is 
not  restricted  to  the  same  type.  Each  occurrence  of  a  /cf-bound  id  may  be  used 
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val  a  =  let  X  =  y  in  X  2  ni 
val  y  =  Xz.z 

Figure  5.4:  Free  identifier  in  a  /ef-bound  definition. 

uniquely,  and  thus  may  have  a  unique  type  associated  with  it. 

Second,  we  must  allow  for  top-level  naming  that  implies  a  definition  may 
contain  free  identifiers.  In  the  Bindley- Milner  type  system  a  type  is  inferred  for  a 
single  expression  that  may  also  contain  free  identifiers,  but  those  free  identifiers  may 
not  refer  to  another  top-level  expression.  A  limited  form  of  naming  is  permitted 
in  the  Hindly-Milner  type  system  using  let  expressions.  Thus  in  our  type  system 
where  a  free  identifier  may  occur  anywhere  in  the  expression  including  a  /et-bound 
id 's  definition,  we  have  to  treat  let  expressions  differently. 

For  example,  consider  the  trivial  program  fragment  in  Figure  5.4.  There  is 
a  dependency  in  a  on  y.  We  only  consider  the  free  identifiers  in  a  when  we  determine 
the  dependencies.  The  Icf-bound  id  x  is  not  free  in  a.  But,  we  must  consider  any 
free  identifier  in  a  even  in  the  definition  of  the  /cf-bound  identifier.  If  we  were  to 
infer  a  type  for  the  /ef-bound  id  x  and  then  type  the  body  of  the  let  expression  using 
the  reduction  technique  we  are  proposing  then  we  would  have  to  apply  the  results 
of  typing  X  to  the  typing  of  the  body  of  the  let  expression. 

The  solution,  when  we  have  an  expression  let  x  =  e  in  e'  ni,  is  to  replace 
each  occurrence  of  x  in  e'  with  e.  This  allows  us  to  maintain  let  polymorphism  and 
deal  with  top-level  naming.  If  a  /cf-bound  id’s  definition  contains  free  identifiers, 
the  substitution  of  e  for  x  in  e'  will  introduce  a  free  identifier  in  the  body  of  the  let 
expression,  which  we  know  how  to  handle,  and  eliminate  the  necessity  of  applying 
the  results  of  one  typing  to  another. 

This  strategy  has  the  disadvantage  that  if  the  /ef-bound  id  does  not  occur 
in  the  body  of  the  let  expression  then  the  definition  of  the  /ef-bound  id  will  not  be 
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L{exp,env)  = 

case  txp  of 

x:  (x,  exp')  €  enr  ?  exp' :  exp 

Ax.Af;  Xx.L{M) 

{M  N):  {L{M)  L{N)) 

let  X  =  M  in  N  ni:  L(N,  ent;(x  >-*  L{M,env)]) 

end  case 

Figure  5.5:  Algorithm  L,  lifts  the  let  expressions  from  the  definitions. 

typed.  We  could  get  around  this  limitation  by  forcing  the  equations  for  the  definition 
of  the  /et-bound  id  to  be  included  with  the  equations  for  the  let  expression’s  body 
and  unified  regardless  whether  id  is  referenced. 

We  have  an  algorithm  L  shown  in  Figure  5.5  which  simply  replaces  each 
occurrence  of  a  /ct-bound  id  in  the  body  of  the  let  expression  with  the  /cf-bound 
id's  definition.  L  takes  as  input  an  expression  and  an  environment  which  consists  of 
pairs  of  /cf-bound  identifiers  and  their  definitions  and  returns  a  /cf-free  expression. 
The  environment  is  initially  empty.  The  algorithm  recursively  calls  itself  until  all  the 
terminal  nodes  have  been  reached.  When  a  let  expression  is  encountered  a  binding 
is  added  to  the  environment  and  the  body  of  the  let  expression  is  processed  using 
the  new  environment. 

2.  EXAMPLE  REDUCTION  AND  UNIFICATION 

In  this  section  we  present  an  example  that  demonstrates  the  type  checker 
in  action.  W'e  look  at  the  type  equations  that  are  generated  by  E  and  the  final  types 
for  the  definitions.  The  final  types  are  inferred  by  unifying  the  equations  returned 
by  E.  applying  the  substitution  that  is  returned  by  unification,  and  closing  the  type. 

Suppose  we  enter  the  following  definition: 

g  =  Xy.Xz.cond  z  nil  (/  y) 
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In  g  cond  and  /  are  free,  and  no  definition  is  provided  for  them  yet.  Also  free  in  g 
is  nil  which  is  defined  in  the  initial  assumption  set  and  has  type  Va./isfa.  E  will 
return  an  associated  type  variable  and  a  set  of  type  equations.  In  these  examples  we 
will  show  the  sub-expression  from  which  the  type  equation  was  generated  next  to  the 
type  equation.  For  g,  the  type  variable  returned  by  E  is  f ,  and  the  type  equations 
that  get  generated  by  E  are: 


Subexpression 

Type  equation 

cond 

teond  ~  ^ 

(5.1) 

z 

0  =  6 

(5.2) 

cond  z 

L  =  6  —*  K 

(5.3) 

nil 

list  Tl  =  (^ 

(5.4) 

{cond  z)  nil 

II 

i 

(5.5) 

f 

if  =  6 

(5.6) 

y 

a  =  7 

(5.7) 

fy 

6  =  e 

(5.8) 

{{cond  z)  nil)  (/  y) 

X  =  e  fi 

(5.9) 

Xz.{{cond  z)  nil)  (/  y) 

1/  =  0  fi 

(5.10) 

Xy.Xz.{{cond  z)  nil)  (/  y) 

^  =  a  —*  V 

(5.11) 

Unification  of  the  type  equations  yields  a  substitution  that  when  applied  to  (  and 
then  closed  gives  us  the  type  Va.V)9.V7.(a {0  — >  7))  for  g. 

If  we  continue  and  provide  a  definition  for  cond  =  Xx.Xy.Xz.z  x  y,  E  will 
return  the  type  variable  0  and  the  following  type  equations  for  cond: 

Subexpression  Type  equation 

Z  C  =  7/ 
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X  a  ss  $ 

Z  X  f)  =  $  -*  t 

y  ‘1  =  K 

{z  x)y  t  =  K  -►  A 

Az.(ri)y  (  = 

Xy.Xz.{zx)y  6  =  7 ( 

Ax.Ay.Az.(2  i)  y  0  =  a  6 

The  type  of  cond  is  Va.V/3.V7.(a  — »  (/9  — ♦  ((o  —♦(/?—»  7))  — ♦  7))).  Now  we  can 
retype  g  since  we  now  have  a  new  type  for  cond.  All  that  is  required,  is  to  reunify 
the  type  equations  given  above  for  y,  only  this  time  we  will  be  able  to  instantiate 
the  type  for  cond,  and  not  have  to  use  an  instantiation  of  the  assumption  Va.o,  for 
the  type  of  cond.  This,  however,  does  not  change  the  type  of  g. 

Suppose  we  define  /  =  Xx.x.  This  definition  will  cause  y’s  type  to  change. 
The  type  variable  for  /  returned  by  E  is  7  and  its  type  equations  are: 

Subexpression  Type  equation 

I  Q  =  0 

Xx.x  -f  =  a  0 

The  type  of  g  is  now  Va.V0.Vy((Q  — >  (list  0  j))  (a  -*  7)). 

But  if  we  change  the  definition  of  /  to  /  =  Xx.nil,  we  will  get  a  type  error 
for  g.  The  type  variable  for  /  returned  by  E  is  7  and  its  new  type  equations  are: 

Subexpression  Type  equation 
nil  list  Q  =  0 

Xx.nil  •<!  sz  6  0 
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This  changes  the  type  of  /  to  Vq.V/3.q  — »  list  0,  that  causes  unification  to  fail  on 
g's  type  equations.  When  g's  type  equations  are  reunified  Equation  5.1  gives  us 
i  =  (tt  — »  (p  — *  {(tt  — »  (p  — »  <t))  -*  <t))).  From  Equation  5.3,  «  =  (p  — ♦  ((jt  —* 
(p  — ♦  <r))  —*  <t)).  Equations  5.4  and  5.5  give  us  A  =  ((ir  — »  (list  g  — ►  a))  — >  a).  In 
Equation  5.6  we  must  instantiate  the  type  of  /.  This  will  give  us  ^  =  t  — ►  list  <f>. 
Then  from  Equation  5.8  we  find  e  =  list  <i>.  Finally,  when  we  try  to  unify  Equation  5.9 
we  find  we  have  to  unify  list4>  with  (ir  — ♦  (listr)  — ♦  <t))  which  fails.  As  a  result-p 
exhibits  a  type  error. 

C.  THE  SYNTHESIZER  GENERATOR 

We  have  implemented  an  on-line  type  checker  using  a  tool  called  The  Synthesizer 
Generator  (SynGen)  [Ref.  6].  This  tool  was  chosen  for  its  ability  to  rapidly  produced 
a  syntax  directed  editor  with  an  X-Windows  interface.  The  language  used  in  SynGen 
is  the  Synthesizer  Specification  Language  (SSL). 

There  are  three  main  parts  of  a  specification  in  SSL.  First,  is  the  abstract 
syntax  for  the  underlying  language  of  the  editor.  The  second  part  is  the  attribution 
and  the  accompanying  attribute  equations.  Lastly,  are  the  unparsing  rules  which 
determine  how  the  program’s  parse  tree  is  to  be  traversed.  Part  of  the  unparsing 
rules  also  determine  what  is  displayed  at  each  node  and  what  the  user  is  allowed  to 
edit.  The  unparsing  rules  also  control  how  expressions  and  terms  are  input  to  the 
system. 

Unfortunately,  SSL  does  not  allow  circular  attribute  equations.  In  order  to  get 
around  the  limitations  of  SSL  we  chose  to  perform  the  type  inference  at  the  root 
of  the  parse  tree.  This  is  a  change  to  the  circular  attribution  given  in  Chapter  IV. 
The  abstract  syntax  used  in  our  implementation  looks  quite  similar  to  that  given  in 
Figure  4.4.  A  program  is  simply  a  list  of  definitions  or  bindings  of  identifiers  and 
expressions  of  the  lambda  calculus  (with  the  addition  of  hi  expressions). 
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An  attribution  is  provided  in  our  implementation  that  is  used  to  pus  up  the 
tree  the  type  variables  and  type  equations  generated  by  E  for  each  definition.  The 
attribution  also  passes  a  type  environment  back  down  the  tree.  At  the  node  for  each 
definition  the  type  variables  and  type  equations  are  generated  by  E  and  passed  up 
the  tree.  .At  the  root,  types  are  inferred  for  the  definitions  and  a  type  environment 
is  passed  back  down  the  tree.  Then  at  the  node  for  each  definition  a  lookup  is 
performed  on  the  environment  that  is  being  passed  down  the  tree  and  the  type  for 
the  current  node  is  pulled  from  the  environment  and  displayed. 

There  is  another  significant  optimization  we  would  like  to  be  able  to  make,  but 
is  not  possible  in  the  framework  of  SSL.  Given  a  sequence  of  definitions 
and  a  set  of  dependencies  (/,  g),  {g,  /i),  (A,  t), . . . ,  and  h  is  updated,  we  would  like  to 
be  able  to  infer  a  type  for  only  h  and  those  definitions  that  transitively  depend  on  /i. 
in  this  case  g  and  /.  Unfortunately  SSL  does  not  provide  any  mechanism  to  detect 
whether  a  parse  tree  has  been  changed,  so  we  end  up  reunifying  the  type  equations 
for  all  definitions.  This  is  undesirable  but  the  implementation  is  still  incremental  to 
the  ••xtent  the  type  equations  are  not  regenerated.  This  is  strictly  a  limitation  of 
SSL. 

To  demonstrate  the  interface  generated  by  SynGen  a  brief  example  is  shown  in 
Figures  5.6  through  5.18.  Figure  5.6  shows  the  programming  environment  at  start 
up.  The  top  pane  is  a  nu-ssage  pane.  The  middle  pane  is  the  editing  window  for 
the  defined  language.  The  bottom  pane  is  a  context  aid  that  shows  at  what  node 
of  the  parse  tree  the  cursor  is  currently  resting.  The  context  pane  also  shows  some 
available  transformations  of  the  current  node  which  would  take  the  user  one  level 
deeper  in  the  parse  tree.  The  displayed  transformations  are  up  to  the  editor  designer 
so  additional  transformations  may  be  defined  but  not  displayed. 

Figure  5.7  shows  the  editor  after  the  context  has  been  changed  to  def  list.  A 
program  consists  of  a  set  of  assumptions  and  a  list  of  definitions.  The  user-input 
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assumption  set  may  be  null  but  there  will  be  a  place  holder  shown  in  the  editor 
window. 

In  Figure  5.8  the  cursor  has  been  placed  on  the  place  holder  for  a  definition.  As 
you  can  see  the  context  has  chzmged  to  a  def  list.  When  the  context  selection  def 
in  Figure  5.8  is  made  the  definition  place  holder  is  transformed  to  the  place  holders 
for  an  identifier  and  expression  as  is  shown  in  Figure  5.9.  The  keyword  val  and  the 
symbol  “=”  are  also  inserted. 

The  definition  has  been  named  g  and  the  context  has  been  moved  to  expres¬ 
sion  in  Figure  5.10.  Once  the  definition  is  named  the  type  is  displayed.  Note  that 
g  is  given  the  universal  type  Vo. a.  The  reason  no  type  is  provided  until  the  defi¬ 
nition  is  named  is  due  to  the  fact  that  the  display  routine  does  a  lookup  based  on 
the  definitions  name  in  the  type  environment.  The  available  transformations  for  an 
expression  are  shown  in  the  context  pane  at  the  bottom  of  the  window.  The  ex¬ 
pression  can  also  be  just  an  identifier  although  this  transformation  is  not  explicitly 
listed.  The  displayed  transformations  are  up  to  the  editor  designer.  Optional  input 
modes  permit  a  very  flexible  combination  of  explicit  and  implicit  input  modes  that 
make  the  editor  as  rigid  or  cis  flexible  as  the  designer  wishes.  One  extreme  would  be 
to  force  the  user  to  explicitly  enter  all  input  with  a  mouse  making  selections  from 
the  context  pane  while  the  opposite  extreme  allows  a  syntactically  correct  expression 
to  be  entered  from  the  keyboard.  This  allows  for  a  friendly  interface  that  does  not 
require  explicit  mouse  selection  for  every  program  transformation. 

Figure  5.11  shows  the  editor  after  the  expression  heis  been  transformed  to  a  A 
abstraction.  Figure  5.12  shows  an  identifier  entered  for  the  A  abstraction  and  the 
context  advanced  to  the  expression. 

In  Figure  5.13  a  second  lambda  abstraction  heis  been  entered.  Figure  5.14 
shows  the  identifier  for  the  second  lambda  abstraction  and  the  context  advanced. 
Figure  5.15  shows  the  rest  of  the  definition  for  g.  The  free  identifiers  in  g  are  cond, 
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Figure  5.6:  The  initial  view  of  the  syntax  directed  editor. 


ml,  and  /.  Recall  nil  is  one  of  the  built  in  operators  with  type  Vq./»s<q. 

In  Figure  5.16  the  definition  for  cond  has  been  entered.  Providing  a  definition 
for  cond  causes  g's  type  equations  to  be  reunified  but  the  type  of  g  is  not  changed. 

In  Figure  5.17  /  has  been  defined  as  the  identity  function.  This  change  causes 
g's  type  equations  to  once  again  be  unified  and  a  new  type  for  g  is  inferred.  This 
time  the  type  of  g  does  change  to  reflect  the  constraints  imposed  by  the  type  of  / 
and  nil. 

The  final  display  in  Figure  5.18  shows  the  effects  of  redefining  /  such  that  it 
causes  g's  type  equations  to  be  reunified.  This  time,  however,  the  unification  process 
fails  due  to  the  inconsistent  use  of  f  \n  g  and  the  type  system  returns  a  type  error 
for  g. 
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Figure  5.9:  The  view  after  the  context  def  is  selected. 


Figure  5.10:  The  view  when  the  definition  is  named  g. 
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Figure  5.12:  The  identifier  for  the  A  abstraction  has  been  entered  and  the  context 
has  been  moved  to  the  expression. 


Figure  5.13:  A  second  A  abstraction  is  entered. 


[E]  MBtitM* 


'il.r  Ldit 


i01 


<JU««Biptions> 

v«l  g  •  \y,  Aj.  j«>g)> 

lyp.  V«  Vp  (X (P  -  «)) 


lap-d^l 

□ 

Figure  5.14:  The  identifier  for  the  second  A  abstraiction  has  been  entered  and  the 
context  has  been  moved  to  the  expression. 
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<Assi]Bptiont> 

«•!  g  •  Ay.  Az.  cond  c  nil  (f  y) 

Tvpt;  v«.yp.vjc.(x  -  <p  -  «»; 

<dtfinitian> 


Figure  5.15:  The  rest  of  the  dehnition  g  has  been  entered 


f"  ll-  L  '^it  .  .'.-.I  , 


M.-lp 


<unaption*> 

9  •  Ay,  At.  eond  i  nil  (f  y) 

ijppt  v«  vp  vx  (jt  -  (P  «»; 
cond  •  Ax.  Ay.  Az.  t  X  y 

T>pt:  v«  vp  vx  (X  -  (P  -  «*  -  <P  «)»; 


Oonlwt;driLM 


Figure  5.16:  The  definition  for  the  conditional  cond  has  been  entered. 


Figure  5.17:  A  definition  for  /  hzis  been  entered  and  p’s  type  has  changed. 


Figure  5.18:  The  definition  for  /  has  been  changed  causing  g  to  be  retyped  resulting 
in  a  type  error  for  g. 
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VI.  RELATED  WORK  AND  CONCLUSIONS 

We  have  shown  that  on-line  type  inference,  an  essential  element  of  any  in¬ 
teractive  programming  environment,  is  possible  using  an  attribute  grammar.  Our 
type  system  obtains  typings  consistent  with  the  Hindley-Milner  type  system.  Type 
checking  is  performed  on-line  and  incrementally.  Modular,  top-down  program  devel¬ 
opment  is  possible  and  the  type  system  maintains  correct  typings  for  each  definition 
at  every  stage  of  program  development. 

The  on-line  type  inference  problem  can  be  reduced  to  that  of  first  order  uni¬ 
fication  on  a  set  of  type  equations.  We  use  the  well  known  reduction  from  the 
Hindley-Milner  type  system  to  first  order  unification.  The  reduction  generates  type 
equations  for  each  definition.  The  type  equations  can  be  saved  and  used  in  future 
typings  for  the  definition  which  would  then  just  require  reunifying  the  type  equations. 
The  type  equations  will  not  change  unless  the  expression  is  modified  (by  editing),  at 
which  point  the  type  equations  would  be  reconstructed. 

The  algorithm  is  incremental  because  we  can  save  the  type  equations  and  only 
reunify  the  type  equations  when  we  must  reinfer  the  type  for  a  definition.  Addition¬ 
ally,  the  attribute  grammar  model  we  propose  has  a  certain  degree  of  incremental 
attribute  re-evaluation  implicit  in  the  model.  Significant  additional  savings  are  pos¬ 
sible  if  the  dependencies  of  the  definitions  are  observed.  The  dependency  relation  is 
a  partial  order  and  thus  we  can  generate  a  total  (linear)  order.  For  a  modified  defi¬ 
nition  we  must  retype  only  the  modified  definition  and  those  definitions  that  depend 
on  the  modified  definition. 
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A.  RELATED  WORK 


MIT's  Id  programming  environment  is  the  current  state  of  the  art.  Our  type 
system  is  more  incremental  because  we  take  advantage  of  the  reduction  from  the 
Hindley-Milner  type  system  to  first-order  unification.  Any  time  a  definition’s  type 
must  be  reinferred  we  only  have  to  reunify  its  type  equations.  The  Id  environment 
calls  H'"  from  the  Hindley-Milner  type  system  which  does  zdl  the  work  of  constructing 
and  unifying  the  type  equations  for  an  expression  every  time  it  is  called. 

B.  FUTURE  WORK 

This  thesis  will  serve  as  the  basis  for  further  research  aimed  at  ultimately  de¬ 
veloping  a  type  discipline  for  a  class  of  implicitly  type  imperative  programming 
languages  in  an  interactive  programming  environment. 

One  issue  we  have  not  addressed  in  this  paper  is  what  happens  if  more  than 
one  definition  is  entered  with  the  same  name.  In  a  syntax  directed  editor  environ¬ 
ment  that  we  have  proposed,  the  ability  to  edit  any  definition  makes  the  process  of 
updating  a  sequence  of  definitions  occur  in  a  framework  that  is  more  intuitive  than 
current  environments  i.e.,  Prolog,  Standard  ML,  and  Scheme.  What  we  have  not 
considered,  however,  is  what  is  the  meaning  of  two  definitions  in  a  sequence  with  the 
same  name.  This  is  called  overloading.  Overloading  is  an  independent  problem  that 
h<is  been  studied  separately  (Ref.  3J.  Overloading  is  beyond  the  scope  of  this  paper, 
so  the  effect  of  multiple  definitions  with  the  same  name  has  not  been  addressed  in 
this  thesis.  Integrating  the  on-line  system  with  overloading  remains  to  be  done. 

Investigating  Sagiv  et  al.’s  CAG  to  NCAG  transformation  is  another  area  where 
further  research  is  needed.  Since  SynGen  is  only  capable  of  handling  non-circular 
attribute  equations  the  simple  attribution  in  Chapter  IV  can  not  be  implemented 
using  SynGen.  Work  remains  in  determining  whether  the  transformation  of  [Ref.  12] 
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can  be  applied  to  transform  the  circular  attribution  of  Chapter  IV,  Another  interest¬ 
ing  research  direction  is  exploring  whether  a  fixed-^Jc  int  finding  attribute  evaluator 
can  be  produced  automatically  using  the  work  of  Farrow  [Ref.  5]. 
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